home *** CD-ROM | disk | FTP | other *** search
- Path: ix.netcom.com!news
- From: David Brownell <brownell@ix.netcom.com>
- Newsgroups: comp.programming.threads,comp.lang.c++,comp.unix.osf.osf1,comp.unix.programmer,comp.object
- Subject: Re: Looking for best design for using pthreads in C++ objects
- Date: Fri, 08 Mar 1996 08:21:33 -1000
- Organization: Dave's VAX
- Message-ID: <31407AAD.1CEF@ix.netcom.com>
- References: <3128ff8b.666031216@news.clark.net> <312A0E5F.7B2C@ix.netcom.com> <31320705.41C6@zko.dec.com> <313DEF19.5B69@ix.netcom.com> <313EDB0B.FF6@zko.dec.com>
- NNTP-Posting-Host: haw-ak1-07.ix.netcom.com
- Mime-Version: 1.0
- Content-Type: text/plain; charset=us-ascii
- Content-Transfer-Encoding: 7bit
- X-NETCOM-Date: Fri Mar 08 12:27:56 PM CST 1996
- X-Mailer: Mozilla 2.0 (Win95; I)
- CC: brownell@ix.netcom.com
-
- Dave Butenhof wrote:
-
- > Having classes with destructors that clean up state, as TRIVIALLY
- > DEMONSTRATED by Locker, is clearly the best way to apply C++ semantics to
- > the problem of protecting thread state invariants against "unusual"
- > routine exit. But the true solution in nearly all cases must go beyond
- > the triviality of Locker to restore data invariants, not merely the state
- > of the mutex!
-
- So I guess we all agree. The original question was a pretty vague
- one, and my response was therefore generic. When you apply generic
- techniques, a "cookbook" approach doesn't work. I did what I could
- to make that clear, but in the discussion all of the original context
- was lost. Part of the peril of being taken out of context!
- --
- David Brownell <brownell@ix.netcom.com>
-